fix: stop one chat conversation from showing as two chat rooms - #709

Problem

While selling on a range order, a peer's messages produced two chat rooms with the same counterparty, each holding the same messages. Both stayed live: a message typed in one appeared in the other after switching rooms.

Root cause

KeyManager.getNextKeyIndex() handed out an index it had just stored as the counter:

Future<int> getNextKeyIndex() async {
  final currentIndex = await getCurrentKeyIndex();
  await setCurrentKeyIndex(currentIndex + 1);
  return currentIndex + 1;   // ← the index deriveTradeKey() will derive next
}

The stored counter is the index deriveTradeKey() hands out next — it derives at the stored index, then increments (key_manager.dart:85-98). So the index reserved by getNextKeyIndex() was the exact one the next deriveTradeKey() derived.

getNextKeyIndex() has a single caller (mostro_service.dart:355), reserving the trade key for a range order's child session. So after a range order release, the next order the user created or took received a trade key identical to the child session's.

Session.sharedKey is ECDH(tradeKey.private, peer.publicKey) (session.dart:203), so two such sessions sharing a counterparty derive the identical ChatKeys pair. Both ChatRoomNotifiers then pass the ownership check event.pubkey == chatKeys.sign.public (chat_room_notifier.dart:212) for the same kind-14 envelopes, each persists them under its own orderId, and each renders its own row — reproducing every detail of the report.

Fix

1. getNextKeyIndex() returns currentIndex — reserves the index the counter points at and advances past it. No collision, no gap: two consecutive calls hand out N and N+1.
2. Chat list collapses rows sharing a conversation key, keeping the newest. Sessions created before this fix are still on disk, so the derivation fix alone does not heal existing devices. An equal ECDH shared key means literally the same messages on both rows, and distinct orders always differ on at least one trade key, so this can never merge two legitimate conversations.
3. SessionNotifier hardening (defense-in-depth, not the trigger): Session.orderId is mutable and reachable through three maps of which only _sessions is keyed by orderId, while promotion paths purged stale entries by identity alone. _emitState() now dedupes by orderId (the persisted _sessions entry wins) and _claimOrderId() drops other in-memory sessions carrying a just-claimed orderId.

Test plan

• getNextKeyIndex regression test in test/features/key_manager/key_manager_cache_test.dart, using a real (unmocked) KeyManager — confirmed RED before the fix (reserved key bf9aaf58… identical to the next derived key) and GREEN after. Also asserts no index gap.
• Three SessionNotifier dedup tests in test/notifiers/session_notifier_test.dart covering saveSession, linkChildSessionToOrderId, registerSessionInMemory — all RED (Expected: <1> Actual: <2>) before, GREEN after.
• flutter analyze clean on lib/.
• Full flutter test suite: no new failures. test/features/disputes/dispute_chat_duplicate_envelope_test.dart fails, but fails identically on clean main (ef3aad30) — pre-existing and unrelated.
• Manual: complete a range order release, then create/take a further order with the same counterparty, and confirm a single chat room.
• Manual: on a device that already shows the duplicate, confirm the list now renders one row and messages remain intact.

Note

Trade-index monotonicity is preserved — getNextKeyIndex still consumes exactly one index. The restore flow's setCurrentKeyIndex(lastTradeIndex + 1) (restore_manager.dart:625,985,1120) already assumes "counter = next index to hand out", which both deriveTradeKey and the fixed getNextKeyIndex now agree on.

This PR does not address the missed push notifications mentioned alongside the report; that is a separate issue.

Summary by CodeRabbit

• Bug Fixes

  • Improved chat history handling by preventing duplicate conversation entries while preserving rooms containing messages.
  • Ensured sessions for the same order are represented only once.
  • Corrected key reservation behavior to prevent reused trade-key indices.
  • Improved reliability when processing incoming chat messages.

• Tests

  • Added coverage for duplicate chat rooms, session records, and key reservations.